Business Intelligence generally refers to a category of software systems and applications used to improve business enterprise decision-making and governance. These software tools provide techniques for analyzing and leveraging enterprise applications and data. They are commonly applied to financial, human resource, marketing, sales, service provision, customer, and supplier analyses. More specifically, Business Intelligence tools can include reporting and analysis tools to analyze, forecast and present information, content delivery infrastructure systems to deliver, store and manage reports and analytics, data warehousing systems to cleanse and consolidate information from disparate sources, integration tools to analyze and generate workflows based on enterprise systems, database management systems to organize, store, retrieve and manage data in databases, such as relational, Online Transaction Processing (“OLTP”) and Online Analytic Processing (“OLAP”) databases, and performance management applications to provide business metrics, dashboards, and scorecards, as well as best-practice analysis techniques for gaining business insights.
In many organizations, data is stored in multiple formats and data sources that are not readily compatible. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multidimensional (e.g., OLAP), object oriented databases, and the like. Further data sources may include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (“ODBC”) and the like. Data sources may also include a data source where the data is not stored like data streams, broadcast data, and the like. Data sources are comprised of values and objects, such as dimensions, columns, rows, attributes, measures and the like, otherwise referred to as data model objects.
OLAP data sources and tools are a subset of BI tools. There are a number of commercially available OLAP tools, such as, for example, Business Objects Voyager™, available from Business Objects™ of San Jose, Calif. OLAP tools are report generation tools and are otherwise suited to ad hoc analyses. OLAP generally refers to a technique of providing fast analysis of shared multidimensional information stored in a database. OLAP systems provide a multidimensional conceptual view of data, including full support for hierarchies and multiple hierarchies. This framework is used because it is a logical way to analyze businesses and organizations. In some OLAP tools, the data is arranged in a schema which simulates a multidimensional schema. The multidimensional schema means redundant information is stored, but it allows for users to initiate queries without the need to know how the data is organized.
OLAP is typically implemented in a multi-user client/server mode to offer consistently rapid responses to queries, regardless of database size and complexity. OLAP helps the user synthesize information through use of an OLAP server that is specifically designed to support and operate on multidimensional data sources. The design of the OLAP server and the structure of the data are optimized for rapid ad hoc information retrieval in any orientation, as well as for fast, flexible calculation and transformation of raw data members on formulaic relationships.
The querying process for OLAP can involve, depending on the specific implementation, writing and executing a query. Multidimensional Expressions (“MDX”) is a query language for OLAP databases, like SQL is a query language for relational databases. Thus, an MDX statement can be used to query for a result from an OLAP data source, i.e., an OLAP data cube. The MDX statements may resemble SQL statements that are used to query for data arranged on rows and columns of a data cube. As with an SQL entry, each MDX query requires a data request (the “SELECT” clause), a starting point (the “FROM” clause), and a filter (the “WHERE” clause). These and other keywords provide the tools used to extract specific portions of data from a cube for analysis, e.g., to extract a slice of the cube.
In one application, MDX queries can be used to specify the addition of a calculation to a hierarchy of multidimensional data. There are two ways to achieve this. The first uses the MDX “CREATE MEMBER” clause:
CREATE MEMBER                [CubeName].[hierarchyName].[ParentName].[MemberName] AS MDX_Expression . . . .The second way uses an MDX “WITH” clause:        
WITH MEMBER                [CubeName].[hierarchyName].[ParentName].[MemberName] AS MDX_Expression . . . .THE MDX_Expression determines the value of the calculation. The calculation need not be a dynamic value and a can be a static value.        
The location of the added calculations in the given hierarchy can only, however, be specified with limited precision. With both the “CREATE MEMBER” and “WITH” clauses above, a calculation may be added to a hierarchy by specifying its parent. The location of a calculation within a sibling group cannot be specified in a native MDX statement.
For example, consider the process flow illustrated in FIG. 1A for adding calculations to an OLAP hierarchy. OLAP hierarchy 100 includes a root member “A” and two children, “B” and “C”. Now consider a user implementing an MDX statement to add a calculation “X” to OLAP hierarchy 100. The user may add the calculation “X” by using either one of the MDX statements above, for example, by using:
CREATE MEMBER [MyCube].[MyHierarchy].[A].[X] as ‘<<expression>>’
This MDX statement specifies that the new calculation “X” is to be added to OLAP hierarchy 100 as a child of “A”. As illustrated in FIG. 1A, OLAP hierarchy 100 already has two children, “B” and “C”. When adding another child to root node “A”, the OLAP server does not know the relative position of “X” relative to its siblings, “B” and “C”. Accordingly, the OLAP server can only position a new calculation as the last child of the specified parent. In this case, the new calculation “X” can only be added after “C” as the last child of “A”, as shown in the updated OLAP hierarchy 105
The user may add another calculation, e.g., “Y”, to OLAP hierarchy 105, using the following MDX statement:
CREATE MEMBER [MyCube].[MyHierarchy].[A].[Y] as ‘<<expression>>’
Similarly, this new calculation “Y” can only be added after “X” as the last child of “A”, as shown in the updated OLAP hierarchy 110. The user cannot, for example, specify that “Y” is to be the first or one of the middle children of “A” in the OLAP hierarchy.
Some types of calculations have natural or intuitive positions relative to siblings. For example, when determining the difference between two members in a list of members it is useful to place the calculation between the two members of interest and not at the end of the list. Also, when creating a calculation for each existing member, pairing the calculation besides the member is helpful to the user.
In the OLAP hierarchy 100 illustrated in FIG. 1A, for example, if “X” were a calculation to add the values of “B” and “C”, it would be useful to place it in between “B” and “C” instead of after “C” as the last child of “A” as shown in OLAP hierarchy 105.
Accordingly, it would be desirable to provide techniques to enable users to create data members in arbitrary positions of an OLAP hierarchy. In particular, it would be desirable to provide techniques to create and evaluate data sets of an OLAP hierarchy according to user-specified positions.